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PREFACE 


The  work  described  in  this  report  was  authorized  under  Contract  No.  DAAD13- 
02-C-0008,  (BAA),  Virtual  Prototyping  System.  The  work  was  started  in  January  2002  and 
completed  in  December  2003. 

The  use  of  either  trade  or  manufacturers’  names  in  this  report  does  not  constitute 
an  official  endorsement  of  any  commercial  products.  This  report  may  not  be  cited  for  purposes 
of  advertisement. 

This  report  has  been  approved  for  public  release.  Registered  users  should  request 
additional  copies  from  the  Defense  Technical  Information  Center;  unregistered  users  should 
direct  such  requests  to  the  National  Technical  Information  Service. 
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VIRTUAL  PROTOTYPING  SYSTEM 


1.  INTRODUCTION 

1.1  Report  Description. 

This  report  contains  an  overview  of  the  Virtual  Prototyping  System  (VPS) 
modeling  and  simulation  capability  that  has  been  developed  for  the  CBRN  Defense  community 
over  the  years.  The  VPS  role,  need,  concept,  and  context  within  Simulation  Base  Acquisition 
SBA  are  presented  in  Section  1 .  Following  sections  provide  details  of:  the  VPS  design  and 
description  (2.);  GUI  and  architecture  details  (3.);  a  proof  of  principal  and  use  example  (4.);  and 
a  review  of  current  status  (5.). 

1.2  Report  Objectives. 

The  major  objective  of  this  report  is  to  demonstrate  the  critical  role  of  VPS  in 
CBRN  defense  systems  acquisition.  This  objective  is  met  by: 

•  The  presentation  of  the  VPS  as  the  major,  viable  and  necessary  capability  in 
CBRN  defense  systems  acquisition, 

•  The  VPS  application  definition, 

•  The  presentation  of  the  tool  specifications 

•  Providing  an  example  of  VPS  use 

A  second  objective  is  to  document  the  current  status  of  VPS.  This  documentation 
includes  the  work  performed  during  the  FY03  effort. 

1.3  Functional  Role  of  VPS. 

Presently  the  CBRN  M&S  community  acquisition  lacks  a  standing  capabilityto 
interactively  link  materiel  development  and  combat  development/planning  into  a  common 
continuum  of  experimentation,  evaluation  and  analysis.  Because  live  testing  of  CBRN  defense 
systems  is  necessarily  quite  restricted,  the  capability  to  link  system  development  with  combat 
development  in  an  operational  context  is  particularly  difficult,  if  not  impossible.  However, 
knowledge  bases  created  by  analysis  of  tests  performed  in  operational  context  are  critical  to 
understanding  operational  worth  and  performance  use  of  CBRN  defense  systems. 

At  present  limited  testing  of  CB  system  components  can  be  accomplished  with 
live  agent  under  very  controlled  laboratory  conditions.  Field  tests  of  CB  systems  can  only  be 
performed  with  simulants  and  not  under  conditions  closely  approaching  operational  employment. 
Yet  understanding  the  CB  environment  impact  on  the  functionality  of  a  given  CB  system  and  on 
the  functional  relationships  between  it  and  various  combat  systems  is  critical  to  the  designer, 
combat  planner,  analyst,  and  warfighter  in  assessing  and  evaluating  such  systems. 
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The  most  plausible  alternative  to  live  testing  is  simulation  testing.  This  approach 
requires  the  virtual  representation  of  systems,  concepts,  and  tactics,  techniques,  and  procedures 
(TTP)  in  a  synthetic  environment.  Recognizing  the  significance  of  virtual  tools  for  development, 
testing  and  analysis,  the  revised  DoD  5000  series  includes  the  development  of  M&S  virtual 
prototyping  capabilities  as  important  to  the  acquisition  process  (Appendix  A).  The  VPS  provides 
the  solution  to  CBRN  modeling  and  simulation  in  support  of  SBA  and  offers  an  important 
element  of  force  preparation. 

The  VPS  M&S  application  provides  the  means  for  integrated,  virtual  CBRN 
testing  and  analysis  and  facilitates  the  linkage  between  CBRN  engineering  and  combat 
developers  throughout  the  acquisition  cycle.  This  is  accomplished  with  a  robust  modeling  and 
simulation  platform  on  which  systems,  systems-of-systems,  and  family-of-systems  are  evaluated 
and  assessed  in  realistic,  virtual  operational  environments.  Implicit  to  the  success  of  this 
approach  is  the  VPS  ability  to  perform  meaningful  analyses  on  the  results  of  a  simulation. 

VPS  ability  to  model  CBRN  defense  systems  gives  it  relevance  in  the  three  DoD 
established  functional  areas  of  M&S  activity:  ACR,  RDA,  and  TEMO.  Because  VPS  can 
operate  in  a  distributed  environment,  a  fully  functioning  VPS  provides  interconnectivity  between 
CBRN  defense  systems  development  (e.g.,  Edgewood,  Dahlgren,  SPA  WARS),  testing  (e.g., 
Dugway  Proving  Ground,  Eglin  AFB),  and  combat  development  (e.g.,  Fort  Leonard  Wood, 
Quantico,  Tyndall  AFB)  centers  throughout  the  DoD.  Although  it  is  not  a  warfighter’s  tool,  VPS 
functionality  and  capacity  for  interconnectivity  provides  beneficial  use  to  the  warfighter. 

As  an  M&S  tool  for  SBA,  VPS  offers  the  following  benefits: 

•  Realistic,  high-fidelity  virtual  test  environments  for  engineering  assessments 

•  Realistic,  virtual  combat  environments  for  assessing  operational  worth  and 
performance  use 

•  Variable  fidelity  of  model  representations  for  CBRN  defense  systems 

•  Linkage  between  system  developers  and  combat  developers  throughout  the 
acquisition  life  cycle 

•  Facilitates  early  warfighter  interaction  in  the  acquisition  cycle 

•  Leverage  existing  community  CBRN  M&S  resources  (modularity,  reusability) 

•  Ease  of  varying  tactical  and  physical  contexts  for  the  evaluations 

1.4  VPS  Concent. 

VPS  is  an  M&S  tool  that  can  be  used  by  a  variety  of  users,  ranging  from  design 
engineers  to  combat  analysts  to  systems  trainers.  Conceptually,  the  Virtual  Prototyping  System 
tool  is  a  process  that  enables  the  assessment  and  evaluation  of  CBRN  defense  systems 
throughout  all  phases  of  the  Acquisition  Process,  from  concept  exploration  through  operations 
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and  sustainment.  VPS  users  with  subject  matter  expertise  will  be  able  to  perform  their  tasks 
from  a  single  station  and  will  not  need  to  be  M&S  experts. 

VPS  enables  implementation  of  Simulation  Based  Acquisition  (SBA)  in  the 
CBRN  community.  In  this  context  VPS  has  particular  relevance  in  systems  concept  and  design 
studies,  allowing  for  the  refinement  of  design  prior  to  prototype  builds,  testing  in  virtual  CBRN 
environments  and  operational  conditions,  and  early  interaction  with  combat  developers  and 
warfighters.  Additionally,  VPS  contributes  to  total  force  preparation,  providing  modeled  CBRN 
defense  systems  for  operational  simulations  and  simulators  performing  operational  worth  and 
performance  use  evaluations  for  commanders. 

To  be  in  line  with  DoD  policy,  computer  codes  and  applications  should  be 
interactive  and  modular.  Too  often,  however,  the  propensity  has  been  to  develop  stand-alone, 
special  purpose  codes.  Contrarily,  a  key  design  feature  of  VPS  is  modularity,  which  establishes 
a  very  robust  and  versatile  M&S  tool.  Importantly,  the  VPS  is  not  intended  to  be  a  monolithic 
end-to-end  simulation  but  rather  the  mechanism  by  which  detailed  representations  of 
conceptual/developmental  CBRN  defense  systems  can  interact  with  other  simulations/simulators 
within  a  synthetic  environment. 

A  feature  that  distinguishes  VPS  from  other  M&S  development  capabilities  is  its 
ability  to  perform  integrated  CBRN  defense  system  level  evaluations  as  opposed  to  individual 
system  component  evaluations.  Currently  the  M&S  community  models  CBRN  defense  system 
components  (sensors,  optics,  electronics,  etc)  independently,  but  the  modeling  of  the  integrated 
components  in  the  context  of  the  system  is  not  available.  The  CBRN  community  also  lacks  a 
system-of-systems  and  a  family-of-systems  capability  that  is  provided  by  VPS.  VPS  addresses 
these  deficiencies  and  enables  assessment  of  the  total  CBRN  defense  system  in  terms  of 
experimentation,  operational  worth,  and  performance  use  in  context  of  the  combat  environment. 

The  principal  function  of  M&S  is  analysis.  VPS  links  model  and  simulation  data 
and  results  with  VPS  and  external  analysis  tools.  These  tools  are  applied  at  various  phases  of 
CBRN  defense  system  development  and  different  in  scope.  For  example,  analysis  tools  for 
system  concept  and  design  typically  will  need  to  include  operational  context.  On  the  other  hand, 
analysis  of  CBRN  defense  system  operation  worth  will  require  an  operational  context  but  will 
not  need  to  include  system  component  level  context. 

Inherent  to  VPS  is  the  capacity  for  conceptual  analyses.  Engineers  will  have  the 
capability  to  design  and  modify  CBRN  defense  systems  at  the  component  level  and  then  analyze 
the  integrated  system  performance  in  operational  context.  Other  applications  include 
engagement  simulations  that  would  use  planned  and  notional  systems  and  capabilities  projected 
for  future  combat  environments.  Results  will  help  evaluate  operational  worth  and  performance 
use  of  projected  CBRN  defense  systems  and  provide  a  situational  context  for  the  future 
battlefield  environment. 

VPS  simulations  are  not  meant  to  replace  live  testing.  However,  the  use  of  VPS 
can  certainly  establish  ranges  of  operation  and  identify  unreliable  designs.  Simulations  can  also 
help  focus  limited  testing  resources  and  capabilities.  Results  of  simulation  testing  may  be  used 
to  extrapolate  test  data  to  other  operational  contexts. 
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1.5 


Need  for  VPS. 


Needs  for  the  VPS  capabilities  within  the  CBRN  defense  community  are 
threefold:  (1)  the  need  for  efficient  and  cost  effective  development  of  operationally  useful 
CBRN  defense  equipment,  (2)  the  need  to  assess  CBRN  operational  worth  and  performance  use, 
and  (3)  the  need  to  meet  defense  acquisition  mandates  and  guidelines. 

VPS  finds  multiple  applications  among  analysts,  requirements  generators  and 
combat  developers,  wargame(s),  schools  and  trainers,  material  engineering  developers  and 
testers.  The  need  for  multiple  applications  is  supported  by  lessons  learned  and  feedback  from  a 
broad  spectrum  of  users.  (See  Section  5.2.2  and  Appendix  B.)  VPS  provides  not  only  a 
mechanism  for  system  development  and  engineering,  but  also  for  system-of-systems 
development  and  conceptual  use  of  systems  in  operational,  testing  and  training  contexts. 
Implementation  of  VPS  allows  early  system  definition  resulting  in  cost  and  time  reduction  in  the 
acquisition  cycle. 

The  VPS  design  is  robust.  While  it  is  being  developed  with  some  specific 
applications  in  mind,  the  total  sum  of  user  desires  and  applications  is  not  supposed.  It  is 
expected  that  once  available  to  the  CBRN  community,  users  will  find  unique  or  unrealized 
applications  for  VPS.  With  this  in  mind,  elements  such  as  Open  Architecture,  distributive 
capability,  and  adherence  to  IEEE,  DIS  and  HLA  standards  are  built  into  the  VPS. 

1-6  Support  of  SBA  and  Acquisition  Benefits. 

The  VPS  is  an  enabling  capability  for  implementing  SBA  in  CBRN  acquisition 
process.  The  Virtual  Prototyping  System  is  specifically  designed  to  define  and  evaluate  CBRN 
defense  systems  in  support  of  the  SBA,  DoD  5000  series  revision  intent  and  acquisition  policy, 
and  CJCSI  3170.  Appendix  A  briefly  highlights  pertinent  items  concerning  M&S  in  acquisition 
reform  and  VPS  relevance  in  context  of  Acquisition  Policy. 

It  is  noteworthy  that  the  VPS  and  SBA  concept  has  been  heartily  embraced  by 
many  developmental  communities  in  both  commercial  and  military  applications.  The  Boeing 
Corporation  and  automotive  companies,  among  many  others,  as  well  as  military  acquisition 
categories  ACAT  1  and  2  developers  have  used  VPS-type  tools  for  years. 

However,  the  CBRN  development  community  has  not  yet  embraced  VPS 
concepts  to  a  large  extent,  possibly  because  tools  being  used  are  not  widely  known  and  because 
their  use  involves  a  paradigm  shift  from  historical  ways  of  doing  business.  Another  very- 
difficult-to-overcome  reason  is  that  articulating  a  strong  requirement  for  VPS-like  tools  has  not 
yet  occurred.  For  ACAT  1  and  2  programs,  developers  are  required  to  use  VPS-type  tools. 
CBRN  defense  equipment  usually  falls  in  ACAT  3  and  4,  which  have  much  less  stringent 
requirements  and  funding  devoted  to  extensive  modeling  development  and  analysis. 

Conceptually  the  cost  and  time  benefits  of  VPS  are  illustrated  in  Figure  1 .  Based 
on  information  compiled  from  numerous  acquisition  programs,  qualitative  cost  vs.  time  curves 
for  historical  acquisition  life-cycles  and  current  acquisition  reform  life-cycles  are  displayed  by 
black  shadowed  and  red  curves  respectively.  Current  acquisition  policies  have  significantly 
reduced  time  and  cost  during  the  acquisition  cycle.  One  of  the  main  reasons  for  this  is  the 
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emphasis  on  early  identification  of  design  and  performance  problems  and  issues.  This  emphasis 
has  the  effect  of  increasing  the  cost  of  the  initial  phases  of  acquisition  but  creating  substantial 
savings  later  in  the  acquisition  cycle. 

Implementation  of  the  VPS  is  expected  to  further  increase  initial  development  and 
design  costs  as  shown  by  the  white  curve  in  Figure  1.  However,  because  the  developing  systems 
can  be  tested  in  a  realistic,  virtual  combat  environment  and  because  the  combat  developer  is 
included  in  the  design  and  development  M&S,  additional  savings  in  cost  and  time  are  realized 
over  the  entire  life-cycle. 


Figure  1.  Notional  VPS  Impact  on  Life  Cycle  Costs. 

(Current  Life-Cycle  and  Historical  Product  Life-Cycle  Graphics  from  Defense 
Acquisition  University  Course  Acquisition  101) 

Reusability  of  many  VPS  modules  and  libraries  (terrain,  weather, 
communications,  etc.)  is  another  benefit  of  the  VPS.  The  initial  cost  of  future  development 
programs  will  decrease,  benefiting  from  the  efforts  of  earlier  programs. 

1.7  VPS  Development. 

Development  of  VPS  will  be  based  on  proof-of-concepts  simulation  used  to 
support  developmental,  analysis,  training  and  testing  efforts  by  the  JSCBD  Tech  Base,  JPEO 
CBD  Acquisition  Programs,  DOD  Test  Ranges  and  Operational  Support  Organizations  (such  as 
JFCOM  and  MANSCEN).  The  envisioned  simulation  system  will  be  able  to  operate  at  specific 
sites  for  focused  evaluations  or  distributed  to  many  sites  for  robust  Joint  Task  Force  (JTF) 
engagement  assessments  of  engineering  alternatives.  Results  of  the  technology  development 
effort  will  directly  transition  to  the  VPS  program  under  the  JPM  Information  Systems. 

Given  the  scope  and  complexity  required  for  a  fully  capable  VPS,  the 
development  will  necessarily  be  phased  within  the  two  application  modes  described  in  Section  2. 
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1.8 


MS&A  Team  Relevant  Background  and  Experience. 


Collectively,  the  MS&A  Team  has  decades  of  experience  supporting  efforts  in  the 
CBRN  defense  system  arena,  including  the  use  of  MS&A  for  SBA  applications.  Team  members 
have  diverse  backgrounds  that  include  researchers,  material  and  combat  developers,  laboratory 
and  field  testers,  and  warfighter  veterans  from  all  service  branches.  This  collective  experience 
and  diversity  of  background  give  the  Team  a  unique  capability  for  designing,  developing  and 
implementing  a  viable  and  robust  VPS. 

Because  of  its  extensive  MS&A  support  of  the  CBRN  community,  the  Team  has 
attained  an  authoritative  understanding  of  M&S  issues  pertaining  to  CBRN  defense  systems, 
meteorological  models,  transport  and  diffusion  models,  CBRN  parameters  and  mechanisms, 
HLA/DIS  architectures  and  operations,  and  CBRN  community  resources.  The  Team’s 
knowledge  extends  to  engineering  models  and  decision  aid  M&S  throughout  the  Joint 
community. 


The  Team  has  played  essential  roles  in  the  development,  implementation,  and 
analyses  of  such  M&S  applications  as  Dial-A-Sensor,  the  NCBR  simulation,  and  the  BioSIM 
experiment  (Section  4.).  In  addition,  the  Team  members  have  developed  and  used  for  analysis 
the  Sensor  Obscuration  Engagement  Simulation  (SOES)  and  the  Smoke  System  Performance 
Model  (SSPM)  /  Cloud  Density  Visualization  Use  (CDVis).  The  SOES  and  SSPM  analyses 
were  SBA  applications  using  M&S  for  the  Army’s  Obscurant  Program. 

Through  its  experience  and  understanding  of  MS&A  relative  to  CB  defense 
systems,  the  Team  has  recognized  the  need  for  and  the  value  of  VPS  as  articulated  by  material 
and  combat  developers  in  support  of  the  acquisition  process.  Based  on  its  experience,  expertise 
and  insight,  the  Team  has  developed  the  VPS  concepts  presented  in  this  report.  The  Team  not 
only  has  the  technical  knowledge  to  successfully  develop  and  implement  VPS  but  also  has  the 
acquisition  knowledge  to  ensure  a  smooth  transition.  Additionally,  the  Team  has  the  analytical 
experience  to  judiciously  apply  VPS. 

Section  4  highlights  one  of  many  successful  Team  activities  in  the  CBRN  MS&A 
field  and  demonstrates  the  Team’s  skill  in  helping  to  develop  and  implement  a  VPS-like 
simulation.  Section  5  documents  the  Team’s  experience  and  efforts  specifically  concerning 
VPS. 

2.  VPS  DESIGN  AND  DESCRIPTION 

2.1  Overview. 

A  high-level  view  of  the  VPS  concept  is  presented  in  Figure  2.  Shown  is  the  VPS 
environment  that  includes  the  VPS  GUI,  VPS  libraries,  the  VPS  Process  (e.g.,  engineering, 
modeling,  simulation  applications,  etc)  and  the  distributed  applications.  Examples  of  HLA  (or 
DIS)  distributed  applications  are  additional  CBRN  defense  system  libraries  and  model  sources, 
environment  models  (e.g.,  JEM,  VSLTRACK),  and  operational  context  simulations  (e.g., 
OneSAF,  JOEF,  JSAF,  JCATS).  Within  the  VPS  Process  reside  the  modeled  CBRN  defense 
system  and  the  simulation.  The  VPS  Process,  through  user  direction,  provides  the  means  for 
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executing  the  simulation  of  interest.  As  noted,  the  VPS  libraries  include  internal  archives  as  well 
as  external  sources.  Implementation  of  external  applications  (distributed  process)  is  controlled 
through  the  VPS  GUI.  Data  required  to  run  external  applications  can  be  provided  by  the  user,  or 
by  selection  of  existing  VPS  library  files,  or  by  selection  of  external  files.  Details  of  the  various 
VPS  elements  are  described  in  Section  3. 

The  “CBRN  Hardware”  and  the  “CBRN  defense  equipment  simulators”, 
components  on  the  right  side  to  the  distributive  architecture  (HLA),  are  entry  points  for  virtual 
simulations.  It  is  through  these  components  that  human  in  the  loop  is  supported.  The  VPS  user 
will  be  able  to  trigger  these  components  from  the  VPS  GUI. 

Shown  at  the  top  of  the  HLA  pipe  in  Figure  2  are  Joint  Evaluation  and 
Experiment  spaces.  The  Joint  National  Training  Capability  (JNTC)  will  be  offering  shared 
evaluation  and  experiment  space  in  which  emergent  systems  need  to  participate.  The  VPS 
allows  for  the  linking  of  CBRN  defense  systems  into  the  S  AF  based  virtual  component  of  the 
experiment  or  evaluation  space  of  the  JNTC. 

2.2  VPS  Application  Modes. 

VPS  is  designed  to  support  two  distinct  application  modes:  (1)  the  engineering 
application  mode,  and  (2)  the  engagement  application  mode.  These  are  not  “stove  pipe”  modes 
but  identify  the  type  of  VPS  user  and  application.  In  either  mode  there  is  considerable  overlap 
and  integration  of  the  VPS  functions  and  resources. 

To  support  the  two  application  modes  VPS  provides  a  common  set  of 
fundamental  capabilities  and  resources.  These  include  a  Graphical  User  Interface  (GUI),  the 
software  toolset  that  models  CBRN  defense  systems,  libraries  that  define  system  components 
and  their  operating  parameters,  libraries  that  define  environmental  and  combat  environments, 
distributed  communications  interfaces,  and  analysis  tools  for  evaluating  system  functionality  in 
realistic,  virtual  environments.  VPS  is  designed  to  operate  on  a  Personal  Computer  or  Work 
Station  in  either  as  a  stand-alone  (primarily  but  not  limited  to  the  engineering  application  mode) 
or  distributed  process  using  HLA/DIS  (primarily  but  not  limited  to  the  engagement  application 
mode). 


Fundamental  VPS  functionality  is  realized  through  a  modular  approach  to 
modeling  integrated  CBRN  defense  systems.  Modularity  requires  individual  component  models 
that  are  maintained  in  the  VPS  libraries  or  supplied  by  the  user.  Evaluation  of  individual 
component  modifications  is  then  accomplished  within  the  context  of  the  integrated  system 
performance.  This  approach  allows  engineer  and  combat  developers  to  evaluate  and  optimize 
the  CBRN  defense  system  rather  than  just  the  individual  components.  This  is  an  important  point 
because,  depending  on  power  requirements,  cycle  time,  weight,  etc.,  optimization  of  one  system 
component  may  possibly  degrade  the  overall  system  performance  or  render  the  system  concept 
untenable. 
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Figure  2.  VPS  Environment.  Major  functional  elements  of  VPS  include  the  VPS  GUI, 
VPS  internal  libraries,  models,  and  modules,  VPS  engineering  tools,  VPS  analysis  tools, 

and  the  distributive  application. 


It  is  important  to  note  that  VPS  only  models  CBRN  defense  systems.  The 
required  component  models  and  simulation  environments  needed  for  system  evaluation  are 
drawn  from  community  sources.  The  VPS  internal  libraries,  built  from  community  information 
and  data,  are  established  to  support  stand-alone  simulations;  external  applications,  libraries,  and 
data  sources  are  used  to  provide  additional  repositories  and  supplement  or  replace  internal 
libraries  in  the  distributed  operation. 


The  above  point,  leveraging  of  community  resources  (libraries,  models, 
simulations,  simulators,  etc)  is  fundamental  to  the  VPS  design  concept.  That  is,  the  use  of 
existing  M&S  community  resources  significantly  reduces  the  cost  and  time  of  VPS  development 
and  implementation.  This  approach  is  compliant  with  modularity  and  reusability  guidance 
included  in  acquisition  strategy. 
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2.2.1 


VPS  Engineering  Application  Mode. 


In  this  mode  the  systems  designer  uses  VPS  primarily  through  the  earlier  decision 
points  and  phases  in  the  Acquisition  Management  Framework  established  by  DODI  5000.2  in 
May  2003.  These  decision  points  include:  Concept  Decision,  Milestone  A,  Milestone  B,  and 
Design  Readiness  Review;  the  phases  include:  Concept  Refinement,  Technology  Development, 
and  System  Development  and  Demonstration. 

In  the  engineering  mode  design  tools  are  used  for  high  fidelity  performance  and 
trade  studies.  This  application  of  VPS  concentrates  on  combining  engineering  concepts  and 
models  with  realistic  physics  and  environmental  conditions  to  determine  optimal  system  design. 
This  mode  will  normally  use  limited  tactical  reality  simulations. 

Design  applications  will  normally  employ  a  stand-alone  engineering  toolset  and 
be  used  by  material  developers  and  Program  Managers.  The  engineering  application  mode 
capability  allows  the  engineer/developer  to  sit  at  his  or  her  workstation  and  ask,  “what  detector 
design  (or  other  piece  of  CBRN  equipment)  parameters  are  necessary  to  meet  required 
performance  characteristics?” 

In  this  application,  the  engineer/developer  uses  menus  or  point  and  click  to 
establish  all  the  sensor  (equipment)  characteristics,  such  as  flow  rate,  sensitivity,  range,  failure 
rates  or  whatever  is  applicable  to  the  CBRN  defense  system  at  hand.  The  developer  builds  the 
CBRN  defense  system  model  from  the  individually  modeled  components  through  drag  and  drop 
technology.  The  developer  also  specifies  the  environment  in  which  he  wishes  to  simulate  system 
operation  and  function.  This  standalone  application  would  rely  on  databases  of  pre-computed 
attacks  and  challenge  levels.  The  software  would  be  distributed  on  a  CD  and  installed  by  the 
developer-user. 

The  systems  developer  will  occasionally  want  to  test  the  system  in  a  realistic 
operational  context.  In  this  instance  the  developer  will  probably  want  to  take  of  advantage  of  the 
VPS  distributive  capabilities,  using  such  applications  as  OneSAF,  etc  to  create  operational 
simulations. 


With  the  VPS  tool,  the  systems  developer  is  only  responsible  for  constructing  a 
model  of  the  specific  system  or  concept  being  developed  or  considered.  The  operational  worth 
and  performance  use  can  then  be  analyzed  in  the  larger  operational  context,  accounting  for 
physics  and  natural  phenomena  provided  by  VPS.  The  results  and  residual  simulation  capability 
can  be  passed  on  to  combat  developers,  testers  and  trainers  for  their  use  with  little  or  no 
modification. 


Major  benefits  of  this  VPS  application  mode  are  the  ability  to  affect  design 
changes  and  test  modifications  before  actually  building  prototype  hardware  and,  because  of  the 
inability  to  test  systems  with  live  or  actual  CBRN  materials  and  effects,  to  provide  the  high 
fidelity,  virtual  combat  environment  that  allows  an  engineering  assessment  of  the  proposed 
system  performance.  These  benefits  led  to: 

•  Early  identification  of  requirement  solution  concepts) 
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•  Early  prototyping  prior  to  build 

•  Early  determination  of  value 

•  Earlier  consideration  of  costs/impacts 

•  Inclusion  of  designer  into  the  operational  worth  equation 

The  sum  of  the  above  benefits  is  expected  to  positively  impact  cost,  time, 
operational  worth,  and  performance  use. 

2.2.2  VPS  Engagement  Mode. 

Combat  developers  and  analysts  will  use  the  VPS  tool  in  engagement  mode  for 
operational  worth  and  performance  use  assessments.  In  this  mode  the  Acquisition  Management 
Framework  areas  of  interest  range  primarily  from  Concept  Development  and  pre-MS  A  through 
the  FRP  decision  point  review  and  include  phases  of  System  Development  and  Demonstration, 
Production  and  Deployment,  and  Operations  and  Support. 

The  engagement  mode  is  focused  on  constructive  &  virtual  simulations  and  it  is 
expected  that  most  applications  in  this  mode  will  be  distributed  over  an  HLA  Federation. 
Realistic  tactical  environments  with  realistic  and  engineering  level  physics  will  be  employed  and 
people/equipment/systems  in  the  loop  can  be  implemented.  Requirements  or  specification 
generation,  concept  exploration,  and  component  or  feature  performance  evaluations  as  well  as 
engineering  trade  off  analyses  will  be  enabled. 

As  noted  in  Section  1,  VPS  is  not  a  monolithic  end-to-end  simulation  but  rather 
the  method  by  which  detailed  simulations  of  conceptual/developmental  CBRN  defense 
equipment  can  interact  with  other  simulations/simulators  within  a  synthetic  environment.  This 
methodology  is  established  to  evaluate  the  range  of  CBRN  defense  system  utilities  in  an 
operational  setting.  VPS  might  be  considered  as  the  high-resolution  analog  to  what  operational 
decision  aid  tools  do  for  decision  aids,  force  structure  or  equipment  issues.  These  tools  provide 
assistance  in,  for  example,  determining  the  number  of  standoff  detectors  needed  in  a  specific 
situation  with  a  certain  probability  of  detection.  VPS  looks  at  what  detector  designs  and 
characteristics  are  required  to  achieve  the  operational  capability  and  what  elements  of  the 
detector  design  can  be  traded  off  to  achieve  the  end  result,  VPS  may  actually  be  the  mechanism 
used  to  determine  the  data  look-up  tables  for  operational  decision  aid  tools.  This  resolution 
partition  of  the  SBA  trade  space  is  shown  in  Figure  3. 

The  key  distinction  between  operational  decision  aid  tools  and  VPS  is  principally 
the  user  base,  resolution  and  output.  Operational  decision  aid  tools  are  geared  toward  providing 
operational  decision  aids  for  staff  action.  VPS  is  geared  to  high  resolution  engineering 
development,  performance  evaluations  and  operational  worth  and  performance  use  assessments. 

Even  though  VPS  is  primarily  a  CBRN  M&S  engineering  and  engagement  tool, 
VPS  can  play  a  vital  role  in  the  operational  decision  aid  arena.  As  indicated  in  Figure  3,  VPS 
analysis  and  simulation  results  of  high  fidelity  studies  regarding  CBRN  defense  system 
responses,  actions,  and  interactions  in  operational  environments  can  be  forwarded  up  the  M&S 
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Figure  3.  VPS  Application  in  the  M&S  Hierarchy. 

VPS  high  fidelity  studies  can  provide  information  and  data  for 
operational  decision  aid  tools. 

hierarchy  as  inputs  into  operational  decision  aid  tools.  Information  relating  to  CBRN  effects  on 
operations  tempo,  causalities,  etc  will  be  improved.  This  use  affords  the  operational  decision  aid 
tools  better  characterization  of  the  battle  environment  and  strengthens  the  validity  of  decision  aid 
outcomes  and  analyses. 


3.  VPS  ARCHITECTURE 

Details  of  VPS  architecture  are  evolving  as  lessons  learned  from  the  proof-of- 
principle  experiments  (e.g.,  Section  4)  and  the  input  from  the  user  community  is  integrated  into 
the  VPS  concept.  At  present  a  workable  architecture  now  exists.  This  first-tier  VPS  architecture 
is  presented  in  Appendix  D. 

3.1  Implementation  of  Architecture. 

Any  VPS  will  have  the  components  as  shown  in  Figure  4.  This  is  a  very  basic 
representation  and  does  not  describe  some  of  the  complexities  that  may  be  inherent  in  the 
component  pieces  (Figure  4  boxes).  Not  indicated  in  Figure  4  is  what  constitutes  the  core 


Figure  4.  Common  Components  Required  in  VPS  Architecture. 

functionality  of  the  VPS;  that  is,  the  interfaces  and  code,  such  as  the  VPS  GUI,  that  enable  the 
components  to  interact. 

Aside  from  the  GUI,  major  work  will  be  required  on  the  components  denoted  by 
the  gray  boxes,  i.e.,  the  CBRN  Simulations  or  Simulators,  and  the  Analysis  Interface 
components.  The  components  denoted  by  the  speckled  boxes,  “Actual  CBRN  Hardware”  and 
the  “Red/Blue  entities  for  operational  context”,  will  need  code  work  but  not  to  the  level  of  the 
components  in  gray.  The  remaining  components  would  require  minimal  development  under 
VPS  as  long  as  these  components  adhere  to  the  HLA  interface  standards.  For  specific  CBRN 
hardware  development  or  analysis,  modification  of  the  components  may  be  required,  but  this 
investment  can  be  recouped  as  an  embedded  training  capability  during  the  fielding  and 
sustainment  phase  of  the  system’s  lifecycle. 

Output  of  the  various  components  will  have  to  match  assessment  needs  of  the 
CBRN  defense  system  to  be  evaluated.  For  example,  if  a  point  CB  sensor  is  being  prototyped, 
the  hazard  prediction  software  may  only  have  to  “publish”  (make  available  on  the  network)  time 
histories  of  the  concentration  accumulated  at  specific  points  on  the  battlespace.  However,  a 
further  refinement  requiring  component  modifications  might  require  information  concerning 
agent  optical  properties,  particle  size  distributions,  relevant  atmospheric  properties  and 
interferents.  The  level  of  fidelity  required  and  the  variety  of  data  required  will  depend  on  the 
sensor  technology  sensitivity  to  these  parameters. 

Similarly,  if  a  standoff  detection  system  were  being  evaluated,  the  hazard 
prediction  software  would  have  to  publish  three-dimensional  cloud  data.  Additional  data  may  be 
required,  such  as  particle  size  distributions,  instantaneous  concentration,  agent  optical  properties, 
and  atmospheric  conditions  and  properties  (e.g.,  winds,  temperatures,  barometric  pressure. 
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aerosols,  gases,  and  particulate  matter  present).  Again,  the  data  required  and  the  fidelity  will 
depend  on  the  detection  technology  being  developed. 

The  two  key  components  of  development  for  VPS,  CBRN  Simulations/Simulators 
and  Analysis  Interface,  will  have  elements  that  are  both  JSTB  spopsored  and  individual  PM  or 
materiel  developer  sponsored.  Under  the  JSTB  portion  of  VPS,  both  components  will  be  built  to 
address  generic  capabilities  like  a  point  biosensor  that  uses  particle  counting  as  a  trigger  or 
standoff  chemical  sensor  using  passive  IR  technology  or  a  semi-permeable  protective  garment. 
The  capabilities  to  evaluate  these  generic  classes  of  CBRN  equipment  will  be  in  the  main  VPS 
program. 

Ideally  the  VPS  modules  and  interface  will  be  highly  adaptable  and  robust  so  that 
any  combat/materiel  developer  would  only  have  to  alter  input  data  sets  and  select  analysis 
options  from  existing  choices.  The  knowledgeable  user  will  have  the  ability  to  build  custom 
libraries,  models,  modules,  etc.  The  PMs  will  have  the  responsibility  for  integrating  multi¬ 
functional  changes  back  into  the  general  distribution  version  of  VPS.  This  process  is  at  the  heart 
of  the  SBA  tenet  to  develop  reusable  and  interoperable  M&S  tools.  Therefore,  the  development 
and  maintenance  of  a  common  core  capability  for  the  CB  Defense  Community  is  desirable. 

VPS  Graphical  User  Interface  (GUI). 

One  of  the  major  coding  efforts  in  developing  the  VPS  tool  will  be  the 
construction  of  the  Graphical  Use  Interface.  This  interface  is  the  user  gateway  to  engineering 
and  engagement  applications,  providing  for  virtual  testing  of  design,  development,  and 
operational  worth  and  function  within  the  context  of  realistic  CBRN  environments.  The  GUI 
provides  linkage  and  access  to  such  varied  applications  as  Computer  Aided  Engineering  (CAE) 
applications  for  engineering  level  system  design  to  access  of  environmental  and  parameterization 
libraries  to  engagement  applications  such  as  OneSAF. 

A  notional,  high-level  design  for  the  VPS  GUI  is  graphically  illustrated  in 
Figure  5.  This  design  is  considered  representative  of  the  VPS  GUI  concept  but  not 
comprehensive  or  final. 

The  overall  structure  of  the  GUI  has  a  standard  “look-and-feel”  familiar  to  most 
program  application  users.  It  uses  menu  bars,  drop  down  menus,  drag-and-drop,  etc  that  are 
prevalent  in  modem  computer  software.  The  VPS  design  logic  facilitates  ease  of  use  and  will 
offer  intuitive  process  flows.  To  facilitate  CBRN  defense  system  design  and  component  linkage, 
the  GUI  engine  is  projected  to  be  a  MATLAB™-like  COTS  application. 

Figure  5  shows  an  example  simulation  process  involving  the  selection  of  a 
Detection  Component  Technology  block  (DC1)  of  the  overall  CBRN  defense  system,  being 
linked  to  a  Radio  Data  Network  (RN1)  and  using  a  Data  Transfer  Technology  block  (DTI). 

Each  of  these  modules  is  a  default  set  of  engineering  structures  obtained  from  engineering  and 
system  libraries  of  high  fidelity  inputs  and/or  models.  Library  pulls  may  be  from  CAE  files, 
engineering  simulations,  or  other  known  sources.  They  may  be  default  components  of  the 
system,  design  concepts,  or  some  other  element  of  the  CBRN  defense  system.  Once 
appropriately  installed  into  the  Operation  Field  via  drag  and  drop,  the  user  can  accept  the  default 
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values,  adjust  values  within  the  control  tables,  or  set  external  sources  using  a  set  of  link  types 
(not  shown  but  involving  arrow  types,  colors,  etc.  for  specific  functionality).  The  user  then 
indicates  number  of  desired  iterations  of  the  simulation  run  as  required.  The  selected  modules 
are  tracked  via  the  Selected  Processes  Field  and  are  saved  for  future  repeat  analysis  of  the  run. 
The  indicator  control  ‘traffic  light’  is  a  representation  of  a  debug  process  that  ensures  the 
appropriate  and  authorized  inputs  and/or  links  are  present. 
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Figures.  Notional  VPS  GUI  Overview.  Components  of  VPS  are  accessed, 
initialized,  implemented,  and  linked  through  the  GUI. 

The  results  are  stored  to  the  appropriate  Report  location(s)/file(s)/output  link(s). 
This  data  can  then  be  used  for  stochastic,  parametric,  or  other  analysis  as  needed.  Internal  to  the 
VPS  structure,  the  data  may  be  run  against  low  fidelity,  closed-value  vignettes  within  a  simplistic 
operational  simulation.  This  provides  ‘goodness’  estimates  particularly  useful  in  ‘what-if 
assessments.  The  data  may  also  be  exported  via  ASCII,  text,  or  other  format  for  use  in  high 
fidelity  operational  simulations  external  to  the  VPS  structure.  This  capability  enables  assessment 
of  the  CBRN  defense  system,  with  desired/required  modifications,  at  the  force  structure  and 
requirements  levels. 
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3.2 


Current  Capabilities. 


From  an  acquisition  development  standpoint  a  Block  IA  capability  of  the  VPS 
exists.  The  components  that  make  up  this  initial  capability  are  shown  in  Figure  6.  A  very 
similar  architecture  was  used  during  the  BioSIM  experiments  described  in  Section  4. 

There  are  other  components  that  represent  various  detection  technologies  like 
standoff  LID AR  (laser  detection  and  ranging),  and  various  other  passive  and  standoff  detection 
technologies.  The  least  mature  component  of  VPS  is  a  robust  analytical  module.  Current 
analyses  still  involve  a  hefty  amount  of  manual  data  transfer,  and  the  M&S  tools  are  very 
specific  to  the  task  at  hand.  When  the  network  was  based  on  distributed  interactive  simulation 
(DIS)  protocols,  commercially  available  data  loggers  were  used  for  data  capture  and  some 
limited  analysis. 


4.  PROOF-OF-PRINCIPLE  AND  USE 

The  U.S.  Army  Soldier  and  Biological  Chemical  Command  M&S  conducted 
several  simulation  experiments  using  VPS-like  concepts,  beginning  as  early  as  1998.  (These 
experiments  were  conducted  prior  to  initiation  and  funding  of  the  VPS  Technology  Base 
program.  The  design,  architecture,  simulations,  and  results  of  these  experiments  significantly 
contributed  to  and  influenced  the  VPS  concepts  and  effort  to  follow.)  The  experiments,  called 
BioSIM,  were  performed  to  establish  tactics,  techniques,  and  procedures  (TTP)  for  a  standoff 
detection  system,  the  LR-BSDS.  The  successful  assessment  of  the  LR-BSDS  system 
demonstrates  the  VPS  engagement  mode  concept  in  a  distributed  environment  and  serves  as  the 
VPS  proof-of-principle.  The  limitations  of  the  BioSIM  distributive  simulation  architecture  were: 

•  Normally  disassociated  simulations  were  modified  to  enable  direct  linkage  at 
some  expense  in  time  and  resources. 

•  The  simulations  used  did  not  permit  stand-alone  (non-distributed)  capability. 

•  The  simulations  were  DIS  compliant. 

Current  versions  of  the  simulations  used  in  BioSIM  are  HLA  compliant. 

4.1  Analytical  Process  as  a  VPS  Proof-of-Principle. 

The  VPS  concept  viability  was  demonstrated  in  1998  using  supporting  both  the 
engineering  and  engagement  application  modes  discussed  Section  2.  The  baseline  scenario  for 
this  study  involved  the  Long-Range  Biological  Stand-off  Detection  system  (LR-BSDS) 
performed  by  the  (then)  Edgewood  Chemical-Biological  Center  M&S  Team.  A  distributed 
simulation  infrastructure  was  used  to  develop  tactics,  techniques,  and  procedures  (TTP)  of 
employment.  Figure  7  depicts  the  support  structure  for  this  analysis. 
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Figure  6.  Current  VPS  Capabilities. 


Two  distinct  BioSIM  experiments  were  conducted  illustrating  the  modularity 
designed  into  VPS.  The  first  experiment  used  ModSAF  entities  to  simulate  the  UH-60  flight 
characteristics.  In  the  second  experiment  the  UH-60  flight  simulator  at  the  Ft.  Rucker  Army 
Aviation  Test  Bed  provided  the  helicopter  flight  characteristics.  The  second  experiment  also 
included  aspects  of  the  VPS  engineering  mode  by  implementing  software  modifications  in  the 
LR-BSDS  operational  parameters. 

The  study  was  performed  using  existing  DIS-compliant  simulations.  As  shown 
above,  the  various  elements  of  the  system  were  simulated  using: 

•  The  NCBR  Environment  Simulator  for  the  agent  dynamics, 

•  The  flight  frame  simulated  by  ModSAF  (experiment  1), 

•  The  flight  frame  and  man-in-the-loop  dynamics  by  a  UH-60  flight  simulator 
(experiment  2), 

•  Terrain  and  cloud  dynamics  by  the  MaK  Stealth  simulation 

•  ADA  threat  by  ModSAF,  and 
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Detector  system  and  operation  (man  in  the  loop)  by  a  LR-BSDS  trainer  with 
DIS  interface. 
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Figure  7.  LIDAR  Study  Architecture. 


These  simulations  were  linked  into  a  central  viewer  and  data  analyzer 
(SIMULYZER)  via  a  distributed  network  domain.  This  process  enabled  both  an  engineering 
examination  of  the  system  and  use  dynamics  in  an  engagement  environment.  The  structure  of 
the  architecture  permitted  both  modifications  of  the  system  and  the  methods  in  which  the  system 
was  used. 


4.2  BioSIM  Results. 

The  evaluation  and  enhancement  of  TTP  for  the  LR-BSDS  were  successfully 
achieved.  Results  of  the  BioSIM  experiments  follow. 

4.2. 1  LR-BSDS  Study  Results. 

•  The  experiment  analysis  resulted  in  modifications  in  TTP. 

•  Experimental  results  also  led  to  LR-BSDS  system  software  modifications 
giving  soldiers  the  ability  to  change  performance  settings  originally 
inaccessible  in  the  field. 


4.2.2  Simulation  Proof-of-Principal  Results. 

•  Demonstrated  viable  process  to  permit  parametric  modification  to  handle 
model  inadequacies  and  scenario  adjustments 
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•  Demonstrated  ability  to  engage  the  system  beyond  the  previous  simulation 
dynamics  due  to  increased  modeling  capability  of  the  VPS  methodology 

•  Recognition  of  previously  invisible  LR-BSDS  system  limitations  due  to  the 
linkage  of  the  flight  dynamics  and  man-in-the-loop  activities  not  previously 
available 

•  Demonstrated  architecture  provided  ‘context’  for  experimenters  enabling 
reusability 

•  Demonstrated  ability  to  exploit  the  architecture  for  other  applications  such  as 
training  or  evaluation  of  interplay  of  different  existing  and  candidate  systems 
or  warfighting  techniques. 


5.  VPS  DEVELOPMENT  EFFORTS 

This  section  documents  VPS  development  efforts  through  FY03.  A  brief 
description  of  work  prior  to  FY03  is  presented  for  history  reference. 

5.1  Pre-FY03  Efforts. 

The  Virtual  Prototyping  concept  for  evaluation  of  chemical  and  biological  defense 
systems  was  first  presented  for  review  by  various  members  of  the  CB  community  in  a  white 
paper  by  Michael  Kierzewski  of  the  MS&A  Team  in  August  of  2001.  Commodity  and  Business 
Area  Managers,  material  developers,  and  other  subject  matter  experts  in  several  different  CB 
fields  provided  commentary  on  the  paper  that  resulted  in  a  series  of  refinements  to  the  original 
concept.  Ideas  presented  as  part  of  the  initial  reports  include: 

•  Extending  the  use  and  improving  the  fidelity  of  T&D  models  used  to  evaluate 
detection  devices  and  CB  protective  clothing  to  all  areas  of  CB  defense 
equipment 

•  Taking  advantage  of  a  virtual  simulation  environment  to  perform  testing  that 
would  be  otherwise  illegal,  dangerous,  or  infeasible 

•  Packaging  systems  in  such  a  way  so  as  to  be  useful  in  constructive  and  virtual 
simulations  for  the  purpose  of  performing  operational  analysis 

•  Incorporate  principles  of  distributed  interactive  simulation  (DIS)  so  that 
systems  under  test  can  be  played  against  human-  and  hardware-in-the-loop 
entities  as  well  as  for  training  purposes 

The  most  significant  task  prior  to  the  FY 03  was  the  development  and 
implementation  of  Dial-A-Sensor™.  This  effort  included  a  “proof-of-concept”  demonstration. 
The  demonstration  used  an  interface  that  enabled  the  analyst  to  control  various  key  performance 
parameters  of  the  Joint  Service  Lightweight  Standoff  Chemical  Agent  Detector  (JSLSCAD)  and 
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immerse  it  into  a  simulated  chemical  environment  (CB  Sim  Suite).  The  results  indicated  that  the 
modified  sensor  behaved  as  expected  demonstrating  the  feasibility  of  the  virtual  prototyping 
concept. 

5.2  FY03  Efforts. 

Efforts  for  the  past  year  fall  into  the  following  categories: 

a.  Development  of  a  notional  architecture 

b.  Capabilities  Assessment  to  include  Prospective  User/SME  Interviews 

c.  Survey  of  Commercial-off-the- Shelf  products  that  might  serve  as  a  starting 
point  for  VPS 

5.2.1  VPS  Architecture  Development  Studies. 

During  FY03  a  notional  architecture  was  developed  as  a  basis  for  VPS  design. 
The  notional  architecture  developed  during  this  effort  will  be  refined  as  details  of  additional  user 
requirements  and  needs  are  assimilated  into  VPS  design.  Issues  that  were  the  focus  of  the  FY03 
efforts  include: 

•  Access  to  desirable  external  libraries 

•  Combining  data  from  simulations/libraries  of  differing  levels  of  fidelity 

•  Distributed  simulation  issues 

The  results  of  this  effort  have  been  incorporated  in  Sections  1, 2,  and  3  of  this 
document.  The  notional  architecture  developed  in  FY03  is  presented  in  Appendix  D. 

5.2.2  VPS  Capabilities  Assessment. 

The  capabilities  assessment  for  VPS  was  generated  through  a  series  of  stages. 

The  initial  stage  was  to  internally  outline  the  desired  capabilities  for  VPS.  Personnel  involved  in 
this  stage  included  material  developers/system  engineers,  combat  developers,  and  experienced 
warfighters.  The  initial  list  was  then  compared  to  the  requirements  listed  in  the  draft  VPS 
Operational  Requirements  Document  (ORD).  A  matured  initial  outline  was  then  given  to  a 
group  of  CB  defense  personnel  to  evaluate. 

To  ensure  VPS  will  provide  capabilities  consistent  with  community  needs  and 
desires,  members  of  the  NBC  acquisition  community  were  polled.  These  contacts  included 
development  engineers  and  managers  in  various  PM  offices,  Commodity  Area  Managers,  and 
CBRN  Subject  Matter  Experts.  Results  from  the  capabilities  assessment  were  consolidated  into 
performance  specifications.  The  list  of  contributors,  desired  capabilities  and  initial  performance 
specifications  is  included  in  Appendix  B,  Section  B.3. 
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Several  common  themes  appear  as  a  result  of  the  polling  process.  Most 
importantly,  the  need  for  a  tool  such  as  VPS  was  strongly  supported.  There  was  also  consensus 
that  a  VPS  tool  would  be  of  great  benefit  to  the  warfighter.  All  those  interviewed  expressed 
belief  that  bringing  the  systems  developer  closer  together  with  combat  developer  and  warfighter 
throughout  the  acquisition  process  has  the  potential  to  shorten  the  acquisition  life  cycle,  placing 
new  equipment  of  operational  worth  and  performance  use  in  the  hands  of  the  warfighter  more 
quickly. 


From  a  more  technical  standpoint  the  survey  contributors  indicated  that 
integrating  models  and  data  of  various  levels  of  fidelity  and  from  different  commodity  areas 
presents  a  significant  challenge  that  must  be  addressed.  To  maximize  its  value,  VPS  should  be 
easily  scalable  with  out  a  great  deal  of  intervention  from  the  analyst.  Also,  to  accurately  model 
the  performance  of  systems,  a  great  deal  of  additional  data  needs  to  be  collected  and  more  and 
better  models  need  to  be  generated,  particularly  in  the  areas  of  human  respiratory  behavior  and 
effects  of  CB  warfare  agents,  and  logistics  models  should  be  incorporated  to  best  measure 
operational  impact.  Finally,  advances  in  computing  power  will  improve  the  speed  with  which 
analysis  can  be  made  and  improved  real-time  interaction  will  enable  the  system  under  test  to  be 
implemented  in  training  situations. 

5.2.3  COTS  Product  Survey. 

The  Clinger-Cohen  Act  (Information  Technology  (IT)  Management  Reform  Act 
of  1996)  mandates  that  Commercial-Off-the-Shelf  (COTS)  surveys  will  be  performed  prior  to 
development  of  DoD  systems.  While  the  desired  capabilities  for  VPS  are  complex  and 
somewhat  unique,  there  exist  several  (COTS)  products  that  could  potentially  serve  as  a  baseline 
from  which  to  build  a  robust  and  flexible  system.  Testimonial  recommendations,  Internet 
research,  and  a  review  of  currently  available  tools  produced  a  set  of  products  with  capabilities 
that  are  similar  those  desired  for  a  mature  Virtual  Prototyping  System.  A  more  critical  review 
was  undertaken  which  resulted  in  a  refined  list  of  candidate  products  that  are  detailed  in 
Appendix  C. 


COTS  Study  Methodology.  An  extensive  market  survey  was  conducted  to  evaluate 
COTS  and  Government  Non-Developmental  Items  (NDI)  on  which  VPS  could  be  constructed. 

The  envisioned  Virtual  Prototyping  System  requires  many  different  attributes,  including 
component  definition  and  manipulation,  data  transfer  protocols,  and  access  to  various  external 
libraries. 

In  context  of  VPS  desired  capabilities  and  attributes,  criteria  were  developed  for 
evaluation  of  COTS/NDI  software.  Because  viable  candidates  come  from  disparate  classes  of 
software,  these  criteria,  listed  below,  were  used  to  help  select  and  rank  candidate  software 
products. 


Evaluation  criteria  of  COTS  and  Government  NDI. 

•  Evaluate  the  technical  ability  to  meet  initial  performance  specifications  as 
defined  during  the  capabilities  assessment 

•  Evaluate  ability  of  the  software  to  function  as  documented  in  this  report 
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•  Assess  level  of  effort/  work/integration  to  make  the  existing  software 
functional  for  VPS 

•  Determine  product  support  infrastructure:  existing  documentation, 
configuration  management  and  training 

•  Determine  extent  of  existing  user  base  for  the  products. 

•  Identify  any  existing  libraries  that  could  be  leveraged  for  VPS  applications. 

•  Assess  the  cost  to  maintain  the  core  baseline  of  the  COTS/NDI  product. 

•  Evaluate  the  ability  to  customize  for  VPS  applications. 

•  Identify  what  the  product  was  designed  for  and  how  it  is  being  used 
(robustness,  flexibility). 

•  Assess  modularity  of  the  product  and  ability  to  support  scalability 

•  Assess  ability  to  support  systems  views  and  the  systems  engineering  process 

The  survey  and  evaluation  process  used  for  this  evaluation  occurred  in  three 
phases.  The  first  phase  involved  a  cursory  look  across  numerous  technologies  to  evaluate  the 
potential  for  use  with  VPS.  Promising  technologies  were  looked  at  in  more  detail  for  the  second 
phase.  Evaluation  at  this  phase  took  the  form  of: 

•  Briefings/demonstrations  and  developer  interviews  (LEAPS™) 

•  Briefings/demonstrations  and  developer  interviews  plus  additional  developer- 
provided  proprietary  documentation  (SPEED™,  MATLAB™/Simulink™, 
Simprocess™,  Epiplex™) 

•  Experienced  prior  user  interviews  (MATLAB™/Simulink™) 

•  Exploration  via  sample  software  and  tutorials  (Simprocess™, 
Mathematica™/Optica™) 

Several  candidate  product  evaluations  were  supplemented  by  additional 
information  obtained  via  web  searches  and  other  public  material  in  addition  to  user  interviews. 
The  third  phase  of  the  survey  consisted  of  a  culling  of  candidate  technologies  to  identify  a  subset 
for  more  critical  analysis.  This  culling  process  was  conducted  using  core  MS&A  team  members, 
a  few  knowledgeable  researchers,  and  representatives  from  the  Joint  PM  for  Contamination 
Avoidance.  This  final  subset  of  candidates  is  presented  in  Appendix  C.  Final  down-select  from 
this  list  will  be  made  as  VPS  development  continues. 
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APPENDIX  A 


ACQUISITION  MANDATES  FOR  M&S 


This  appendix  is  intended  only  to  highlight  the  salient  points  of  the  pertinent  acquisition 
directives,  instructions,  and  policies  as  they  relate  to  modeling  and  simulation.  The  appendix 
provides  the  foundation  for  VPS  relevance,  fit,  and  worth  to  the  CBRN  acquisition  process.  It  is 
not  intended  to  be  a  tutorial  on  the  DoD  acquisition  process  nor  is  it  inclusive  of  all  DoD 
documents  establishing  requirements  or  guidance  for  M&S  in  the  acquisition  process. 

A.1  Defense  Acquisition  System  5000.1, 5000.2  and  5000.2-R  Documents 

In  October  2002,  Deputy  Secretary  of  Defense,  Dr.  Paul  Wolfowitz,  rescinded  Acquisition 
documents  DoD  5000.1,  50001.2,  and  5000.2-R,  provided  interim  guidance  and  directed  revision 
of  the  cancelled  documents  5000.1  and  5000.2.  Dr  Wolfowitz  stated  the  intent  of  the  DoD  5000 
series  revisions  is  to  "...create  an  acquisition  policy  environment  that  fosters  efficiency, 
flexibility,  creativity,  and  innovation.  ” 

The  revised  DoD  5000.1  Directive  (May  2003)  states  that  Test  and  Evaluation  support  be 
employed  throughout  the  defense  acquisition  process  and  include  the  integration  of  M&S  with 
T&E  processes.  The  DoDI  5000.2  elaborates  on  the  use  of  M&S  and  states  that  Program 
Managers  shall  plan  for  M&S  throughout  the  acquisition  life  cycle. 

The  5000.2-R  is  now  no  longer  a  regulation  but  has  been  retained  as  a  guide.  This  document 
provides  expectation  for  best  practices  and  portrays  the  importance  of  early  system  definition  in 
cost  and  schedule  reduction. 

A.2  Chairman  of  the  Joint  Chiefs  of  Staff  Instruction  (CJCSI)  3170.01C 

The  purpose  of  CJCSI  3 1 70.0 1 C  is  “. .  .to  establish  policies  and  procedures  of  the  Joint 
Capabilities  Integration  and  Development  System  (JCIDS).”  These  procedures  “..support  the 
Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS)  and  the  Joint  Requirements  Oversight  Council 
(JROC)  in  identifying,  assessing  and  prioritizing  joint  military  capability  needs  as  specified  by 
(the  JCIDS  process)”. 

The  CJCSI  asserts  that  the  identification  of  capability  gaps  and  potential  solutions  must  be 
supported  by  a  robust  analytical  process,  a  process  that,  among  other  processes  and  tools, 
includes  M&S. 

A.3  Simulation  Based  Acquisition  (SBA) 

Simulation  Based  Acquisition  (SBA)  process  is  a  major  initiative  within  DoD.  The  goal  of  SBA 
is  produce  quality  systems  of  high  military  worth,  faster,  and  at  lower  cost  than  traditional 
means.  The  DoD  continues  to  improve  the  acquisition  process  as  addressed  by  the  Simulation- 
Based  Acquisition  (SBA)  process  initiative.  This  initiative,  formalized  in  the  revised  DoD  5000 
series,  includes  the  development  of  M&S  virtual  prototyping  capabilities  in  all  services. 
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In  the  M&S  Domains  (RDA,  ACR,  and  TEMO)  the  purpose  is  to  intelligently  utilize  M&S 
technologies  throughout  the  acquisition  process.  Models  and  simulations  are  reusable  and 
interoperable  across  different  acquisition  phases  and  activities.  The  interface  and  sharing  of 
M&S  tools  and  technologies  across  the  M&S  domains  is  defined  by  Simulation  and  Modeling 
for  Acquisition,  Requirements,  and  Training  (SMART). 
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APPENDIX  B 


CAPABILITIES  ASSESSMENT 


B.l  Initial  Capabilities  Assessment.  The  following  people  contributed  to  the  initial 
capabilities  assessment. 

1 .  W  alton  Dickson,  MAN  SCEN 

2.  Sonia  Taylor,  MANSCEN 

3.  Nancy  Kammerer,  PM  NBC  Defense 

4.  MS&A  team  members,  ECBC 

B.2  Survey  and  Interviews:  The  summaries  in  this  section  are  identified  by  the  contributors 
and  contain  the  salient  points  of  their  position. 

B.2.1  Linwood  Halsey,  Joint  Services  Lightweight  Standoff  Chemical  Agent  Detector, 
interview  date:  4  Mar  2003 

Mr.  Halsey  provided  us  with  some  system  schematics  of  the  JSLSCAD.  Comments  related  to 
VPS  requirements  include: 

•  Provide  a  test  chamber  environment  in  the  toolset  to  allow  for  comparison  between 
the  various  test  methods. 

•  Ability  to  specify  data  output  file  format  (i.e.  ASCII,  binary) 

•  Meet  JTA  requirements 

•  Allow  for  Error  and  Bug  Reporting 

B.2.2  Kirkman  Phelps,  Contamination  Avoidance  Commodity  Area  Manger,  interview  date: 
9  Apr  2003. 

Mr.  Phelps’  comments  include: 

•  Common  tool  for  Training,  Testing  and  Design 

•  Link/Interface  with  other  tools 

■  Engineering  Analysis  (FEA) 

■  Computer  Aided  Engineering/Design 

■  Electronics  Design 
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■  Optics  software 

■  Physics  Based  Software 

■  Physics  (First  Principle) 

•  Easily  Scalable 

B.2.3  Mike  Abaie,  Artemis  Program,  interview  date:  25  Apr  2003 

The  process  to  select  a  software  package  to  model  system  was  initiated.  This  effort  was  cut  short 
to  use  SPEED™. 

•  Wanted  a  library  of  current  systems 

•  Concept  of  Operations  (CONOPS) 

B.2.4  Steven  Gotoff,  Patrick  Air  Force  Base,  (Steel  Centurion),  interview  date:  8  May  2003 

At  the  time  of  selection  for  SPEED™,  there  was  no  comparable  software.  Sent  him  requirements 
document  to  review. 

B.2.5  Ngai  Wong,  Passive  Standoff  Detection  Technology,  26  August  2002 
Ngai’s  comments  include: 

•  VPS  should  answer  the  question  of  how  quickly  an  agent  needs  to  be  identified,  as 
opposed  to  merely  detected 

•  Begin  with  user  priorities  and  work  down 

•  Establish  a  standard  database,  perhaps  one  per  Enabling  Capability  under  the  JFOCs, 
into  which  new  critical  operationally  significant  details  can  be  stored  and  accessed  by 
the  entire  CB  community;  VPS’s  role  should  be  to  connect  these  databases  in  a 
meaningful  manner 

•  Establish  thresholds  of  useful  knowledge;  a  researcher  at  the  6. 1  level  may  need  to 
account  for  atomic  interactions  whereas  a  developer  at  the  6.4  level  probably  does  not 

•  The  target  customer  is  more  likely  the  operation/tactical  level  users;  perhaps  a  better 
name  for  VPS  would  be  the  Operational  Technology  Simulation  Assessment  Tool 

B.2.6  Sandy  Quinn,  Decontamination  Technology,  19  August  2002 

Sandy  provided  assistance  in  constructing  a  schematic  diagram  for  the  decontamination  process. 
Fler  comments  included: 
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•  Proper  simulation  of  the  decontamination  process  would  account  for  logistics 
burdens;  sustainability  an  issue  at  engagement  level  and  above.  Decon  requires  lots  of 
water  and  systems  depend  upon  significant  power  supply:  generators,  batteries,  etc. 

•  Fidelity  of  simulation  might  dictate  different  modeling  techniques.  For  simulation  at 
the: 


■  Phenomenological  level,  use  chemistry 

■  Engagement  level  and  above,  use  time  blocks 

■  Engineering  level,  some  combination  of  both 

•  Use  field  data  to  generate  success  rate  algorithm  to  determine  if  process  needs  to  be 
repeated 

B.2.7  Bill  Fritch,  Joint  Services  General  Protection  Mask  (JSGPM),  17  September  2002 

Bill  took  part  in  test  trials  for  the  JSGPM  and  compared  those  results  with  predictions  made  by 
the  Respiratory  Encumbrance  Model  (REM).  His  comments  include: 

•  The  factors  that  impact  mask  performance  are  complicated  and  difficult  to  model 
because  of  variations  in  different  users,  such  as: 

■  Respiratory  system  health  and  performance 

■  Face  size  and  shape 

•  An  important  part  of  VPS  should  be  the  inclusion  of  or  connection  to  an  effective 
Human  Behavior  Model 

■  These  models  are  not  very  mature  and  lack  fidelity 

•  Stochastic,  as  opposed  to  deterministic  processes,  are  probably  better  suited  to 
determine  outcomes  for  mask  performance  at  engagement  level  simulations 

•  At  this  time,  it  is  still  cheaper  and  faster  to  quickly  construct  physical  prototypes  to 
evaluate  new  concepts 

B.2.8  Dave  Caretti/Karen  Coyne,  Respiratory  Protection  Technology,  25  September  2002 

Dave  led  the  effort  to  create  the  REM,  a  GUI  driven  model  designed  to  aid  engineers  and 
physiologists  determine  the  effects  of  changes  to  specific  mask  attributes  on  mask  and  user 
performance.  Karen’s  research  focuses  on  the  complex  interactions  of  the  factors  that  influence 
respiration  and  basal  metabolism.  Their  comments  include: 

•  REM  did  not  correlate  well  with  results  of  field  tests  for  JSGPM 
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•  Many  variables  play  a  role  in  respiratory  performance,  including: 

-  Health 

■  Weight 

■  Core  body  temperature 

■  Humidity  inside  and  outside  of  system 

■  Activity  level  and  duration 

■  Environmental  factors 

•  Effective  models  would  require 

■  Significant  computing  resources 

■  Improved  understanding  of  human  behavior  and  response  to  outside  stimuli 

•  Physical  prototypes  are  still  easier  and  cheaper  to  construct  when  evaluating  effects  of 
attribute  changes 

B.3  VPS  Initial  Performance  Specification  List.  Based  on  interviews  and  contributions  the  list 
below  is  a  compilation  of  performance  requirements  for  the  Virtual  Prototyping  System  toolset. 

1 .  CB  Systems  to  be  Modeled 

a.  Contamination  Avoidance 

b.  Collective  Protection 

c.  Decontamination 

d.  Individual  Protection 

e.  Information  Systems  Tools 

2.  Stand-Alone  Tool 

a.  Evaluate  System 

b.  Provide  Input  and  Get  Output 

3.  Environments  Library 

a.  Lower  Fidelity,  Easily  Reproducible  Environments 

b.  Test  Chamber  Representation 
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4.  Distributed  Simulation 

Immerse  System  into  Synthetic  Environment 

5.  Detailed  Evaluation  using  SAFs 

6.  Multiple  and  Disparate  System  Evaluation  - 

7.  Extensive  Component  Library 

8.  Output  Model  of  System/Sub-Systems  without  the  overhead  of  unnecessary  code 

9.  User  Defined/  User  Modified  Components 

1 0.  Output  to  Pertinent  Commercial  Tools 

1 1 .  Ability  to  exchange  multiple  fidelity  models  into  system  representation 

12.  Components  will  have  definable  inter-relations 

1 3 .  Open  Architecture 

14.  Open  Source 

15.  Interchangeable  modules 

1 6.  Ability  to  run  different  system  configurations  in  a  batch  process 

1 7.  Produce  a  system  representation  with  major  sub-components  in  a  relational 
structure  (with  a  multi-fidelity  representation) 

1 8.  System  model  can  be  immersed  in  JEM  and  JOEF 

19.  Established  systems  can  have  an  output  model  to  be  distributed  in  simulations 
(i.e.,  JOEF)  without  the  need  for  VPS  code. 

20.  Ability  to  specify  output  format  (i.e.,  ASCII,  binary) 

2 1 .  Produce  data  for  analysis 

a.  High/Low  fidelity  options 

b.  Save/  Over-write  data  options 

22.  JTA  Compliant 

23.  Built  in  identifiers  that  will  establish  software  integrity 

24.  Error  and  Bug  reporting 
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25.  Configuration  Management 

Controlled  releases 

26.  Verification,  Validation  and  Accreditation 
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APPENDIX  C 


COMMERCIAL  OFF-THE-SHELF  (COTS)  SURVEY 


Those  COTS  and  Government  NDI  software  packages  identified  in  the  third  phase  of  the 
selection  process  are  presented  here  (Section  5.2.3  for  details  of  the  selection  process.)  They 
have  been  ranked  based  on  VPS  selection  critical  and  recognized  applicability  to  VPS 
applications.  These  packages  and  the  rankings  are  given  in  Table  C.l.  Details  concerning  each 
package  are  in  the  following  sections  of  this  appendix. 

Table  C.l 

Identification  and  Ranking  of 
Candidate  VPS  Software 


Software  Package 

Ranking 

COTS  or  G-NDI 

Mathematics 

Laboratory/Simulation  Link 
(MATLAB™/Simulink™) 

1 

COTS 

Simulation  for  the  Performance 
Evaluation  and  Exploitation  of 
Designs  (SPEED™) 

2 

COTS 

Simprocess™ 

3 

COTS 

Epiplex™  Solutions:  Process 
Development  Environment 

4 

COTS 

Leading  Edge  Architecture  for 
Prototyping  Systems  (LEAPS™) 

5 

G-NDI 

Mathematica™  and  Engineering 
Systems  Libraries  such  as 
Optica™ 

6 

COTS 

The  sections  below  provide  comments,  descriptions,  and  brief  reviews  concerning  the  products 
in  Table  C.l 
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C.l  Mathematics  Laboratorv/Simulation  Link  (MATLAB™/Simulink™) 

Major  Advantages:  (1)  existing  user  base  for  CB  defense  system:  (2)  extensive 
documentation  and  user  training  available:  (3)  extensive  libraries  (signal  process. 
networks);(4)  additional  libraries  can  be  added:  (51  demonstrated  HLA/DIS  capability  and 
availability;  (6)  very  strong  systems  engineering  processes  capability. 

Disadvantages:  requires  user  expertise  /  mitigated  bv  available  training. 

MATLAB™  is  a  platform  for  performing  a  variety  of  technical  computing  tasks  including 
algorithm  development,  generating  tables  and  graphs,  running  software  simulations,  and 
analysis.  The  user  can  implement  any  calculation  by  writing  routines  in  several  languages, 
including  C,  C++,  and  FORTRAN.  MATLAB™  provides  many  built-in  algorithm  toolboxes  that 
include  formulas  from  many  fields  without  the  need  to  write  code  such  as: 

•  Signal  and  image  processing 

•  Data  analysis  and  statistics 

•  Mathematical  modeling 

•  Control  design 

Output  can  be  made  available  using  various  included  statistics  tools,  graphically,  or  in  text/table 
format. 

Simulink™ 

•  Works  in  conjunction  with  MATLAB™  via  its  neatly  transparent  link 

•  Provides  drag-and-drop  functionality  for  joining  components  and  systems 

•  Additional  libraries  for  commonly  used: 

■  Components 

■  Processes 

■  Algorithms 

•  Allows  for  introduction  of  new/novel  components 

While  using  the  built-in  functions  and  components  is  easily  done,  definition  for  new  components 
specific  to  CB  require  that  either  new  objects  be  created  and  added  to  the  resident  set  of  libraries 
or  that  the  systems  engineer  be  very  knowledgeable  about  the  working  of  the  component  and 
capable  of  writing  code  to  make  Simulink™  work  easily. 
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C.2  Simulation  for  the  Performance  Evaluation  and  Exploitation  of  Designs  (SPEED™) 


Major  Advantages:  (1)  currently  used  in  a  CB  acquisition  (ARTEMIS)  program;(2)  ability 
to  customize  software  (i.e..  user  can  modify  core  source  code). 

Disadvantages:  immature  documentation  and  training. 

SPEED™  was  developed  to  assist  in  the  concept  development  and  pre-design  stages  of  optical 
sensors.  It  is  an  object-oriented  program  that  provides  a  drag-and-drop,  black  box  approach 
where  an  object’s  properties  are  user-defined.  Right  clicking  on  a  component’s  box  opens  a  GUI 
that  allows  the  user  to  define  an  object’s  pertinent  properties.  Adding  simple  line  connectors 
between  the  sub-components  of  a  system  can  link  component  objects,  which  can  subsequently  be 
recognized  as  new  systems  or  sub-components  of  larger  systems.  Systems  can  be  linked  similarly 
to  other  objects  that  include  environment  objects  such  as  atmospheric  properties  and  terrain 
features. 

SPEED™  Features: 

•  Uses  XML  for  database  definitions 

•  Links  with  Open  Database  Connectivity  (ODBC)-compliant  databases 

•  Is  HLA-compliant 

Core  Model: 

•  Written  in  C++  (contains  some  source  code  in  FORTRAN  run  as  an  executable) 

•  Various  Output  Formats 

■  Text 

■  Tables 

■  Graphs 

•  Provides  the  analyst  with  the  ability  to  define  statistically  significant  values 
(confidence  intervals,  performance  thresholds,  etc.) 

•  Built  in  mathematical  analysis  tools 

SPEED™  does  require  significant  computation  power  and  processing  speed  as  a  result  of  this 
flexibility.  While  SPEED™  is  flexible  and  powerful,  it  does  require  fairly  expert  input  decisions 
and,  at  this  time,  is  well  developed  only  for  engineering  associated  with  sensors  and  optical 
systems.  However,  the  architecture  may  be  appropriate  for  any  set  of  engineering  systems  with 
the  inclusion  of  additional  properties/parameters  libraries. 
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C.3  Simprocess™ 


Maior  Advantages:  (1)  architecture  support  of  systems  engineering  process:  (2)  good 
documentation. 


Disadvantages:  not  yet  used  for  CB  simulations  -  primarily  used  in  business  applications. 

Simprocess™  is  a  flexible,  easy  to  use  systems  modeling  tool  that  was  developed  primarily  to 
model  business  practices  and  methods.  Users  create  a  set  of  “black  boxes”,  each  of  which 
represents  a  particular  object  or  process. 

•  Easily  defined  parameters 

•  Boxes  linked  by  drag-and-drop  connectors 

•  Alerts  user  to  improper  connections 

•  Double-clicking  on  a  process/object  allows  the  user  to  define  and  assign  properties 
and/or  parameters  to  sub-components  of  the  system 

•  Provides  a  suitable  framework  for  analyzing  a  system-of-systems. 

•  SIMPROCESS™  Output: 

■  Table,  text  or  graphical 

■  Includes  flexible  statistics  package 

■  Can  be  used  on  intermediate  or  final  results 

■  Option  to  observer  output  real-time 

Simprocess™  is  easy  to  use  and  understand.  However,  re-use  of  components  is  difficult  (no 
drag-and-drop  library  for  components).  Further,  significant  effort  would  be  required  to  build 
complex  components  (see  reference  1 3) 

C.4  Epiplex™  Solutions:  Process  Development  Environment 

Maior  Advantages:  (1)  similar  capabilities  as  SIMPROCESS™:  (2)  plug  and  play  links  to 
other  windows  applications. 

Disadvantages:  not  yet  used  for  CB  simulations  —  primarily  used  in  business  applications. 

Epiplex™  is  an  XML  based  process  analyzer  and  capture  system,  which  is  used  for  a  variety  of 
purposes  within  the  software  community.  It  was  initially  developed  to  provide  software  system 
process  capture  for  the  development  of  training  documentation  and  intervention  (macro) 
construction.  However,  the  power  of  the  process  rapidly  grew  to  include  the  capability  for 
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cross-application/system  capture,  documentation,  intervention-engineering,  and  process  data 
capture/analysis.  Specific  Epiplex  Modules  include: 

Epiplex™  Remote  Process  (Knowledge)  Capture  System  (ERPCS) 

•  Spontaneously  capture  (remotely)  processes  in  use  across  enterprise 

•  Store  and  catalog  Process  in  Enterprise  Repository 
Epiplex™  Business  Process  Analyzer  (EBP A) 

•  Analyze,  evaluate  and  identify  broken  and  processes  efficiently 

•  Rapidly  develop  process  models  and  best  practices 

•  Simplify  user  feedback  and  confirmation  of  process  improvements 
Epiplex™  Knowledge  Provisioning  System  (EKPS) 

•  Integrate  multiple  enterprise  applications  and  workflow  products  with  common  user 
interface 

•  Embed  knowledge  into  processes  and  common  user  interface 

•  Embed  manual  processes  into  common  user  interface 

•  Automate  user  side  processes 

•  Auto-generate  business  process  content  such  as  simulation  based  training,  “How-To” 
Documentation  and  “Show  Me”  Animation 

•  Provide  seamless  environment  to  manage  and  integrate  content  from  disparate 
environments  and  systems 

Epiplex™  Process  Benchmarking  System  (EPBS) 

•  Easily  define  and  set  up  real  time  process  intelligence  for  key  personnel 

•  Rapidly  set  up  best  practice  and  process  performance  benchmark 
Epiplex™  Desktop  Knowledge  Capture  (EDKC) 

•  Capture  processes  to  feed 

•  Assessment  of  best  practice  compliance 

•  Real  time  process  intelligence  and  process  performance  evaluation 
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Epiplex™  Desktop  Knowledge  Provisioning  (EDKP) 

•  Track  user  context  to  extract  from  Enterprise  Process  Repository  precisely  relevant 

■  knowledge,  best  practices,  information  and  references 

■  user  process  performance  support  and  automation  resources 

•  Obtain  business  process  simulation  based  training,  how-to  documentation  and  “show- 
me”  animation 

•  Personalized  content 

Epiplex™  Process  Intelligence  Dashboard  (EPID) 

•  Obtain  real-time  intelligence  on  processes 

•  Obtain  real-time  process  performance  information 

•  Personalize  dashboard 

C.5  Leading  Edge  Architecture  for  Prototyping  Systems  (LEAPS™! 

Major  Advantages:  (1)  indirect  links  to  engineering  solid  model  and  indirect  links  to  finite 
element  analysis;  (2)  Object  Oriented  Programming. 

Disadvantages:  (1)  legacy  codes  in  system  that  must  be  maintained  while  developing  CB 
applications  -  LEAPS  is  designed  for  ship  and  submarine  acquisition:  very  limited 

documentation;  (3)  limited  use  of  COTS. 

LEAPS™  was  initially  designed  to  improve  the  Navy’s  ship  and  submarine  acquisition  process. 
It  provides  a  framework  for  model  interaction  and  uses  an  object  orient  data  structure.  The 

primary  focus  of  LEAPS™  is  as  a  transition  between  engineering  design  and  engineering 
analysis. 

•  Design  models  are  converted  and  stored  as  tessellated  models 

•  Tessellated  models  can  be  viewed  through  web  interface 

•  Metadata  and  attributes  are  associated  with  the  stored  models 

•  Users  utilize  an  API  to  develop  their  product  meta-models  and  translators 

The  LEAPS™  infrastructure  resides  at  the  Naval  Surface  Warfare  Center,  Carderock  Division 
(NSW CCD)  and  is  run  from  remote  locations  via  the  API.  At  the  user  level,  all  that  is  required 
is  a  desktop  computer  and  a  data  port.  While  it  is  very  powerful  and  flexible,  it  appears  that 
LEAPS  requires  that  the  analyst  be  very  knowledgeable  in  specific  fields  of  engineering  and 
could  entail  significant  training  to  maximize  its  power 
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C.6  Mathematica™  and  Engineering  Systems  Libraries  such  as  Optica™ 

Major  Advantages:  mathematical  processes  are  very  strong. 

Disadvantages:  (1)  linking  of  components  to  build  systems  is  limited:  (2)  distributed 
capability  not  demonstrated. 

Mathematica™  is  a  powerful  and  flexible  computation  tool  providifig  a  platform  for  performing 
calculations  on  data  -  either  present  within  the  application  or  provided  by  an  external  source  - 
and  manipulating  and  combining  symbolic  expressions,  a  process  Wolfram,  Inc.  refers  to  as 
symbolic  programming.  It  comes  equipped  with  tools  for: 

•  Manipulating  matrices 

•  Solving  algebraic  and  differential  equations 

•  Performing  statistical  analyses 

Mathematica™  can  be  extended  to  include  user-defined  processes  by  means  of  scripts  in  Maple 
or  other  scripting  languages  or  routines  written  in  C,  Java,  or  other  standard  languages.  However, 
while  Mathematica’ s  power  is  virtually  unlimited  at  the  basic  math  and  computational  level,  it 
does  not  provide  the  ability  to  graphically  group  and  manipulate  systems  as  encapsulated  objects. 
Ideally,  a  systems  engineer  wants  the  means  to  package  together  and  control  a  set  of  object 
attributes  and  easily  connect  objects  to  perform  evaluations  on  both  isolated  systems  and 
systems-of-systems.  While  Mathematica™  may  have  great  use  as  a  module  for  performing 
specific,  clock-time  intensive  calculations,  it  would  require  significant  energy  and  resources  to 
build  the  graphical  user  interface  or  some  other  relatively  easy  input  method  necessary  to  make  it 
ready  to  serve  as  the  building  block  for  a  systems  engineering  analysis  tool. 

Optica™  Optica™,  a  product  by  Wolfram,  Inc.,  makers  of  Mathematica™,  is  a  module  designed 
specifically  to  extend  the  functionality  of  Mathematica™  for  the  purpose  of  solving  problems  in 
ray  optics.  Its  connection  to  Mathematica  is  similar  to  the  relationship  between  MATLAB™  and 
Simulink™.  Optica™  provides  a  variety  of  built-in  optical  elements  such  as 

•  Lenses 

•  Mirrors 

•  Gratings,  and 

•  Prisms 

Attributes,  such  as  shape  and  refractive  index,  can  be  varied  by  analyst  input.  A  catalog  of 
common  optical  media  such  as  glasses,  crystals,  and  fluids,  can  be  used  as  is  or  be  modified  to 
create  new  components  with  unusual  shapes  and  properties.  Optica™  has  drag  and  drop  palettes 
that  include  standard  optical  elements,  as  well  as  electronic  and  solid  state  components,  all  of 
which  allow  for  some  user  defined  parameters.  While  Optica™  offers  flexibility  and  can  be  used 


APPENDIX  C 


43 


easily,  the  focus  of  Optica™  is  on  investigating  basic  optical  phenomena  and  may  not  be  suitable 
for  evaluation  of  complex,  engineered  systems. 
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APPENDIX  D 


VPS  NOTIONAL  ARCHITECTURE 


The  VPS  Toolset  is  a  modular,  data  driven  simulation  tool  where  the  scientist/engineer/analyst 
controls  input  parameters  and  simulation  operation  through  a  graphical  user  interface  and  have 
the  option  of  viewing  the  results  in  a  variety  of  output  formats.  Data  for  the  simulation  is  stored 
in  external,  linked  libraries.  When  additional  data  is  or  a  correction  to  existing  data  becomes 
necessary,  changes  can  be  made  in  the  databases.  Hard  code  changes  to  the  core  models  are  not 
required. 

Figure  D.l  is  a  depiction  of  the  1st  Tier  Architecture  for  the  VPS  Toolset.  The  COTS  baseline 
will  have  libraries  added  which  will  provide  data  for  the  system  representation  modules.  The 
items  in  the  lower  row  of  the  flowchart  are  the  functional  components  of  VPS  that  the  user  will 
control.  JEM,  JOEF  and  other  models  will  be  used  to  increase  the  overall  functionality  of  VPS. 


Figure  D.l:  VPS  1st  Tier  Architecture 
D.l  Commodity  Area  Functional  Flow  Diagrams 

The  following  section  establishes  baseline  architecture  for  the  components  library  of  the  VPS 
toolset.  The  functions  of  the  different  commodity  areas  are  broken  into  tiered  structures  as 
defined  by  the  systems  engineering  process.  This  outline  is  chosen  as  an  adaptation  of  the  way 
that  VPS  can  be  used.  This  organization  of  the  functional  requirements  can  correspond  to  the 
modular  approach  that  can  be  taken  using  VPS.  The  upper  tier  functions  could  correlate  the  low 
fidelity  representation  of  the  system.  As  the  system  becomes  better  defined,  the 
functions/components  become  more  developed.  The  model’s  fidelity  will  increase  with  the 
maturity  of  the  system  development.  The  diagrams  below  are  intended  to  be  a  baseline  for 
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systems  in  the  various  commodity  areas.  Subject  Matter  Experts  (SME)  will  outline  details  of 
the  functions  related  to  the  systems  in  their  respective  fields. 

D.  1 . 1  Contamination  Avoidance  (Sense) 

The  functional  block  diagrams  below  illustrate  the  components  of  the  CA  system.  The  1st  Tier 
Functional  Diagram  (Figure  D.2)  will  contain  the  information  necessary  for  a  low  fidelity 
representation  of  the  system.  As  the  development  cycle  progresses,  the  upper  tier 
blocks/modules  can  be  replaced  with  the  lower  tier  blocks  which  represent  more  detailed 
functional  requirements.  For  sake  of  expediency,  all  of  the  functions  will  not  be  expanded  in 
lower  tier  depictions.  This  structure  lends  itself  to  selecting  the  fidelity  of  the  model  that  is 
appropriate  for  the  system  and  the  task  being  executed. 


Figure  D.2:  1st  Tier  Functional  Diagram  for  a  Contamination 

Avoidance  System 

FigureD.3  provides  more  detail  related  to  the  Sampler  and  Detector  functions  of  a  CB  Sensor. 
The  3  tier,  as  depicted  in  Figure  D.4,  breaks  these  functions  out  even  further.  This  process  can 
be  continued  until  the  desired  fidelity  is  reached. 


Figure  D.3:  2  Tier  Functional  Diagram  for  a  Contamination  Avoidance  System 
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2.2  Signature  Processing 


Figure  D.4:  3rd  Tier  Functional  Diagram  for  a  Contamination  Avoidance  System 

D.  1 .2  Protection  (Shield) 

The  figures  below  represent  the  functional  requirements  for  a  protection  system.  The  basic 
functions  for  collective  and  individual  protection  are  the  same.  As  this  is  evaluated  further, 
functions  related  to  individual  and  collective  protection  will  be  interchanged  such  as  that  of  a 
pump  versus  human  respiration.  Figure  D.5  is  the  1st  tier  architecture  for  a  protection  system. 


Figure  D.5:  1st  Tier  Functional  Diagram  for  a  Protection  System 

Figure  D.6  illustrates  the  2nd  tier  structure  of  the  filtration  sub-system  of  the  overall  protection 
system.  Figure  D.7  expands  the  functional  process  of  the  filtration  media  into  3  sub-functions. 
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Figure  D.6:  2nd  Tier  Functional  Diagram  for  a  Protection  System 


Figure  D.7:  3rd  Tier  Functional  Diagram  for  a  Protection  System 
D.1.3  Decontamination  (Sustain) 

The  functions  of  a  decontamination  system  are  depicted  below.  The  1st  tier  of  the 
decontamination  system  is  depicted  in  Figure  D.8.  The  function  chosen  to  further  evaluate  is 
decontamination  system  (Figure  D.9). 


Figure  D.8:  1st  Tier  Functional  Diagram  for  a 
Decontamination  System 
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2.0  Decontamination  System 


Figure  D.9:  2nd  Tier  Functional  Diagram  for  a  Decontamination  System 


The  3rd  tier  in  Figure  D.10  is  outlined  for  a  sprayer  system.  To  provide  an  example  of  the 
modularity  of  VPS,  Function  2.1  (Decontaminate)  is  a  point  at  which  a  chemistry  model  can  be 
introduced  into  the  evaluation. 


2 A _ 

Decontaminate 


Dissemination 

Source 


Figure  D.10:  3rd  Tier  Functional  Diagram  for  a  Decontamination  System 
D.2  Investigation/Leverage  Areas  of  Interest 

The  VPS  model  has  the  capability  of  joining  with  other,  external  elements  as  described  in  the 
sections  above.  The  following  three  areas  are  of  particular  interest: 

•  Common  Simulation  Framework 

•  Leverage  Model  Architecture  for  Technology,  Research  and  Experimentation 
(MATREX)  Science  and  Technology  Objective  (STO)  Architecture  Layout  (Joint 
approach.  Joint  Virtual  Battlespace  (JVB)) 

•  Computer  Aided  Software  Engineering  Tools 
D.2.1  Common  Simulation  Framework 

The  Common  Simulation  Framework  (CSF)  is  an  open-source,  government  owned  system  for 
making  simulation  systems  modular  and  easily  reusable.  The  configuration  management  for 
CSF  resides  at  Redstone  Arsenal.  The  following  overview  is  excerpted  from  the  Common 
Simulation  Framework  (CSF)  Programmer ’s  Guide : 
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Over  the  last  several  years,  the  simulation  community  has  recognized  the  need  for  an  object- 
oriented  simulation  framework  that  allows  users  to  assemble  component  models  into  simulations 
in  a  user-friendly  environment.  The  Common  Simulation  Framework  (CSF)  has  been  developed 
to  address  this  need.  The  CSF  is  implemented  entirely  in  C++.  The  structure  of  the  CSF  is  based 
on  a  “client/server”  model  that  separates  server  (model)  code  from  client  (GUI)  code.  When 
applied  to  simulation  modeling,  this  structure  insulates  the  models  from  changes  in  the  GUI  code 
that  is  often  highly  platform  dependent.  To  ensure  that  models  developed  within  the  CSF  are 
portable,  all  models  are  implemented  using  server-side  frameworks  based  on  the  Standard  C++ 
library.1 

D.2.2  Leverage  MATREX  STO  Architecture 

The  purpose  of  the  MATREX  STO  is  to  develop  a  persistent,  secure,  distributed  and  reusable 
environment  where  simulation  models  and  system  components  can  be  “plugged”  into  an 
established  architecture  as  needed  and  then  “played”  for  analysis,  evaluations  and  technology 
trade-offs  in  support  of  the  Objective  Force,  Army  transformation,  other  Services,  and  joint 
acquisition  programs.  The  architectural  development  will  be  leveraged  to  mitigate  development 
costs  for  VPS.  In  addition,  the  models  and  tools  represented  in  MATREX  will  greatly  increase 
the  potential  functionality  of  VPS. 

The  following  is  a  generic  description  of  the  MATREX  architecture.  A  detailed  explanation  of 
the  architecture  is  provided  in  the  MATREX  System  Architecture  Description,  March  03 
(Research,  Development  and  Engineering  Command).  VPS  architecture  will  be  governed  via  the 
position  of  common  building  blocks  (standards  and  interfaces).  Figure  D.l  1  (source:  Tank- 
Automotive  and  Armaments  Command  (TACOM)  Defense  Standardization  Symposium;  DCS 
Corporation;  March  03)  depicts  this  concept  graphically. 


Inter- Vehicle 
Standards/Interfaces 
(Platfoim/C4ISR) 


C4ISR  Domain  components  must  be  integrated  into 
the  platform  computing  environment  and  rationalized 
against  platform  system  requirements,  to  Include 
performance  specifications  and  system  architecture 


Intra-Vehicle 

Standards/interfaces  Inter-Vehicle 

Standards/Interfaces 

(Platform/Simulation) 


M&S  performance  and  functional  models  must  be 
transitioned  into  design  and  physical  models. 


Figure  D.ll:  Architecture  Structure  for  Commonality 

The  VPS  system  incorporates  existing  commonalities  to  establish  linkage  via  similar  structure 
and  interfacing  as  shown  by  Figure  D.12. 
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Intelligence  Models  — 
Design  Patterns  — 
Task  Models  — 
Decision  Artifacts  — 


VPS  Architecture 


o 


—  Functional  Hierarchy 

—  Reusable  components  {Legacy  &New} 

—  Architecture  Standards  and  Interfaces 

—  Test  Suites 


^91 


Figure  D.12:  Commonality  Structure 


D.3  Data  Handling 

Data  handling  will  depend  nearly  exclusively  on  the  model/structure/software  selected.  It  must 
interface  with  all  external  simulations  being  associated  with  the  VPS  processes  (i.e.,  the  higher 
fidelity  models).  Thus,  the  structure  will  need  to  be  associative  and  visible  to  each  of  these 
architectures. 

D.4  Environment  Modeling 

Environment  modeling  will  be  based  upon  currently  accepted  simulations.  VPS  will  be  open  for 
library  interface  with  these  models  as  required.  A  basic,  ‘standard’  library  will  be  included  in  the 
baseline  VPS  model  for  use  in  a  non-distributed  structure  for  initial  analysis  and  modeling. 
Higher-level  fidelity  will  be  achieved  via  the  distributed  processing  mode. 

D.5  Component  Modeling 

Component  modeling  is  the  heart  of  the  VPS  simulation.  VPS  will  contain  the  ability  to 
structure  simulation  aspects  per  the  requirements  of  the  scientist/engineer/analyst  from  a  list  of 
common  algorithms  and/or  independently  constructed  models.  Additional  attributes  have  been 
discussed  in  the  information  within  this  report. 

Because  of  the  distributed  processing  capability  of  the  VPS  architecture,  multiple  components 
may  be  modeled  independently  and  combined  into  a  structured  system  for  operational  analysis. 
The  independent  modeling  mode  also  permits  independent  and  sub-component  analysis  as 
required  by  the  user. 


APPENDIX  D 


51 


